[pull] canary from vercel:canary - #1394

### Problem
1. Next computes the warmup cache key while `SOME_ENV_VAR` is unset.
2. Rendering ends up setting `SOME_ENV_VAR`.
3. Final prerender expects the cache entry to exist, but the env var
changed, so the key changed and it's a miss.
4. Unexpected miss and bailout.

This lead to
```
Error: Route "foo": Unexpected cache miss after cache warming phase during prerendering. This is
likely caused by non-deterministic arguments that differ between the cache warming phase and the
final prerender phase (e.g. unstable array order). Ensure that arguments passed to cached functions
are deterministic.

Error: Route "foo": Next.js encountered uncached or runtime data during
prerendering.
```

### Solution

~~Instead, snapshot the env vars once at module evaluation time of the
`use cache` function. This ensures that the cache key doesn't change
over time. This is also how it worked thus far (with deployment id as
the cache key): changing the env var over the lifetime of the process
didn't lead to a reexecution of the `use cache` function~~

RDC already stores cache entries generated in the previous phase (be it
during `next build` multi-phase rendering, or from prerender->resuming
at runtime). Root params are already excluded from the cache keys when
storing in RDC. Also exclude the env var hash bit, to conform to this
system of preventing tearing (at the cost of potential staleness).

### What?

Globally order all emitted Turbopack ECMAScript chunk items by module
path, including items nested inside batches. Browser and Node.js chunk
emitters now consume the same flattened, ordered result.

### Why?

The previous ordering compared only the first module in each item or
batch group. Remaining modules in a batch stayed together even when
their paths belonged elsewhere in the global order, reducing locality
between similar modules and slightly worsening gzip compression.

For `bench/basic-app`, production JavaScript chunk gzip sizes changed as
follows while raw bytes and chunk counts stayed unchanged:

| Output | Before | After | Change |
|---|---:|---:|---:|
| Browser chunks | 1,619,643 B | 1,619,314 B | -329 B (-0.020%) |
| Server chunks | 792,379 B | 792,186 B | -193 B (-0.024%) |
| Combined | 2,412,022 B | 2,411,500 B | -522 B (-0.022%) |

### How?

The shared ECMAScript chunk-content accessor now flattens resolved item
and batch groups and sorts every module by `(path, module id)`. Keeping
this ordering in the shared layer gives browser and Node.js output
identical deterministic behavior and removes duplicated emitter-side
sorting.

### Verification

- `cargo fmt --all -- --check`
- `cargo check -p turbopack-browser -p turbopack-nodejs`
- `cargo test -p turbopack-browser -p turbopack-nodejs`
- `pnpm build-all`
- Clean baseline and candidate production builds of `bench/basic-app`

<!-- NEXT_JS_LLM -->


<!-- fleet d30d9e3f-6885-4665-ae08-b37fa6151b95 -->

---------

Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>

### What?

Reduce Turbopack ECMAScript chunk size by emitting strict module
factories in a shared strict-mode scope instead of repeating `"use
strict"` in every factory.

The chunk format now chooses among the existing flat representation, a
mixed representation with flat non-strict factories plus a nested strict
array, and an all-strict representation that wraps the complete chunk in
a strict IIFE. Each factory is generated through the existing single
code path; the production minimizer removes its redundant directive when
the factory is created inside a strict wrapper. Browser and Node.js
emitters share the mode selection and serialization implementation,
while the runtime remains compatible with the existing flat format.

### Why?

ECMAScript modules are always strict, so large chunks currently repeat
the same directive across many factories. Moving strictness to the scope
where those factories are created removes redundant bytes without
copying arrays or changing strict/sloppy execution semantics.

For `bench/basic-app`, this reduces total raw JavaScript by 16,831 bytes
(0.161%). Partitioning factories changes compression behavior, resulting
in a 1,286-byte (0.051%) gzip increase across all JavaScript; format
selection therefore remains based on emitted raw bytes.

### How?

- Determine each chunk item's strictness from the already-collected
chunk metadata.
- Generate every factory once with its normal directive, then rely on
the minimizer to remove redundant directives inside strict wrappers.
- Compare the expected minified directive bytes removed with the exact
wrapper bytes added and keep small chunks in the existing flat format.
- Keep non-strict factories flat in mixed chunks and append strict
factories as an array produced by a strict IIFE.
- Wrap the complete registration/export in a strict IIFE when every
factory is strict, keeping those factories flat and avoiding a nested
array entirely.
- Use the shorter arrow IIFE when the target supports it, with a
function IIFE fallback for older targets.
- Preserve source-map sections, scope-hoisted module IDs, factory
naming, and ordering within each partition.
- Add focused strict, sloppy, mixed, all-strict, old-target, and
below-threshold coverage and update affected Turbopack snapshots.

### Verification

- `cargo nextest run -p turbopack-tests -E 'test(snapshot)'`
- `cargo clippy -p turbopack-ecmascript -p turbopack-browser -p
turbopack-nodejs`
- `pnpm build-all`
- `pnpm --dir turbopack/crates/turbopack-ecmascript-runtime/js
check:nodejs`
- `bench/basic-app` production Turbopack build, repeated to confirm
deterministic size totals

<!-- NEXT_JS_LLM -->


<!-- fleet 528ffe69-eb27-466b-a132-842272a782cf -->

---------

Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>

…pgrade (#98560)

### Why?

Async Request API codemods can leave temporary casts that still require
application-specific repairs. Those locations need explicit markers,
while optional feature adoption needs to be distinguishable from
required version migrations.

### How?

Add `@next-codemod-error` comments to temporary `UnsafeUnwrapped*`
casts, with instructions for completing the repair. Preserve documented
ignores and avoid duplicating casts or markers when the transform runs
again. Mark generated Cache Components opt-outs with
`@next-codemod-ignore`, a removal condition and a link to the adoption
guide.

Add `upgrade --skip-adoption` to skip the Cache Components `instant =
false` transform and partial-prefetch adoption cleanup. Required
migrations and normal dependency and bundler selection keep their
existing behavior. Both adoption transforms can still be run explicitly.

Stacked on #98560.

### Why?

Users need to distinguish unfinished codemod repairs from intentional
feature-adoption opt-outs.

### How?

Document `@next-codemod-error` and temporary `UnsafeUnwrapped*` casts in
the codemod guide, with examples and a link to the Async Request APIs
migration guide. Explain when an inapplicable suggestion can be marked
`@next-codemod-ignore` with a reason.

Show the ignore comment emitted for Cache Components opt-outs and
explain that it does not block compilation.

### What?

Prevent the OpenTelemetry instrumentation e2e collector from losing span
exports when an exporter reuses an idle localhost connection. Add
focused coverage for the collector's connection behavior.

### Why?

Keeping the collector listener alive for each application's full
lifetime removed the earlier close-and-rebind gap, but did not eliminate
every socket failure. Node's HTTP server could still time out an idle
keep-alive socket retained by the exporter's Undici pool. A later export
could race that closure, lose spans with `UND_ERR_SOCKET` or
`ECONNRESET`, and leave otherwise unrelated trace assertions with
incomplete trees.

The canary.28 failure was investigated separately and is not this
mechanism: it occurred in the release-enabled Rspack matrix when a
custom server exited during startup. This change is limited to the
residual non-Rspack collector race and does not alter Rspack coverage or
release snapshots.

### How?

Successful collector exports explicitly close their HTTP connection.
Each export therefore uses a fresh local connection instead of retaining
a socket that the server may reclaim while idle. The regression test
asserts this response contract directly, avoiding timing-dependent
coverage of the race.

### Verification

- Node 20.9.0, webpack dev, React 18.3.1: 5 consecutive focused runs, 55
tests passed per run
- Node 20.9.0, webpack start, React 18.3.1: 99 passed, 13 existing skips
- `pnpm test-types`
- Prettier and ESLint on changed files

<!-- NEXT_JS_LLM -->


<!-- fleet e4b8ed15-4a06-4727-a634-fddcc27c11fc -->

Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com>
Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>